The invention relates to relocating context information in header compression.
The rapid progress in IP (Internet Protocol) technology during the last few years has also expanded the potential of using different IP-based applications outside the conventional Internet data transfer. IP-based telephony applications in particular have developed at a fast pace, as a result of which an ever expanding part of the call transmission path even in conventional telephone networks (PSTN/ISDN, Public Switched Telephone Network/integrated Services Digital Network) and mobile networks (PLMN, Public Land Mobile Network) can, in principle, be implemented by utilising IP technology.
Especially in mobile networks, IP technology offers many advantages, since in addition to the conventional voice services of mobile networks, which could be provided by means of various IP voice applications, mobile networks will provide more and more different data services, such as Internet browsing, e-mail services, games, etc., which are typically most preferably implemented as packet-switched IP-based services. This way, IP layers arranged in mobile system protocols could serve both audio/video services and various data services.
In mobile networks, it is especially important to utilise the limited radio resources as efficiently as possible. This, for its part, complicates the utilisation of the IP protocols in the radio interface, because in IP-based protocols, the proportion of various header fields of the transferred data is very large, and correspondingly, the proportion of payload is small. In addition, the bit error rate (BER) of the radio interface and the round-trip time (RTT) of the uplink and downlink directions may in bad conditions increase a great deal, which causes problems in most known header field compression methods. This has created a need to develop a header compression method suitable for different IP protocols, which would be especially suited for real-time data transfer over the radio interface: efficient header field compression which can, however, be used in conditions in which bit error rates and round-trip times increase a great deal.
For this purpose, IETF (Internet Engineering Task Force) has lately been working on the standardisation of a header field compression method known as ROHC (Robust Header Compression). One idea behind the development of ROHC is that there is a great deal of redundance between the several IP header fields used in data packet transfer, not only inside the data packet, but also between them. In other words, a large amount of the information in the header fields does not change at all during the transfer of the data packets and is thus easy to reconstruct at a receiver even though it is not transmitted. Only a small part of the header fields are such that the information they comprise requires attention during compression. Further, ROHC comprises several compression levels, whereby the efficiency of the compression increases when moving on a higher level. ROHC always tries to use the most efficient compression possible, in such a manner, however, that before moving on to the next level, a sufficient reliability of operation of the level is always ensured. ROHC also has the typical characteristic that it leaves several matters essential for the use of a compression method to be handled by the lower link layer.
ROHC, like typically all header compression techniques, require the storing of context information used for compression and decompression of headers of packets at the compressor (transmitter) and decompressor (receiver) and to initialize the compression/decompression process by sending essentially full headers. What is meant by the context information is a state which the compressor uses to compress the header field to be transmitted and the decompressor uses to decompress a received header field. When header compression/decompression is utilized with a wireless link, headers sent on the uplink traffic are compressed by the mobile terminal and decompressed by a network entity. In the downlink traffic, the network entity compresses the headers, and the mobile terminal decompresses the headers.
In normal operation of compression/decompression, the decompression context information is in synchronism with the compression context information, in the sense that when the decompression context information is used to decompress a header that was compressed with the compression context information, the original uncompressed header is reconstructed. Both the compression context information and decompression context information may be continuously updated by the compressor and decompressor respectively, in such a way that the two contexts stay in synchronism.
When a mobile terminal is handed over to another radio cell served by another network entity, if no efficient procedure is defined to relocate the context information to the new network entity, the header compression/decompression process has to again proceed through reinitialization, which entails sending full headers in both the downlink traffic and the uplink traffic. Such a reinitialization with full headers is both disruptive of the ongoing communications and consumes the bandwidth over the air interface. Therefore, a mechanism has been developed for transferring the compression and decompression context information from the old network entity to the new network entity by taking a snapshot of the compression and decompression context information between the old network and the mobile terminal and delivering this snapshot to the new network entity to be used as the compression and decompression context information. The compression and decompression are typically stopped for the time required for taking the snapshot and transferring it to the new network entity.
One problem in the context information relocation procedure described above is the long time needed for taking the snapshot and transferring it to the new network entity, while the compression and decompression must be stopped. This results in a significant break in real-time data transfer. Thus this break should be made as short as possible. Another problem is that in mobile systems, the mobile terminal does not typically know in advance, when the handover on the network side from the old network entity to the new network entity will take place. Therefore, the mobile terminal will continue to compressing the uplink data and transmitting it to the old network entity, even though the old network entity has already stopped decompressing said data due to the handover. In that case the compressed data packet sent by the terminal may be lost.